Shin Hu
   |
Posted - 2008.11.06 15:41:00 -
[1]
 Originally by: Mister Xerox
Originally by: CCP Lingorm
Hope that answers all the questions and brings this thread upto date with a wall of black and blue.
Hey, uh, guys... how difficult would it be to add a layer mask?
If it's a BPO (-1 runs) = Layer mask (to make it blue)
If it's a BPC (+X runs) = No layer mask (it's just plain gray/white).
Yes, it would be very handy to see runs remaining as we see with ammo stacks, but if it would be to heavy on the DB then we can forgo that. But I don't see how a simple client-rendered mask/nomask would be so heavy on the engine.
Note: Client rendered, so no additional server calls are required. The client querries the server and layers the items as they're parsed.
Ok, again. The point is: There is no Run-Entry in the Inventory-list!
The Inventorylist is a plain db table just with basic informations that is usefull for all itemtypes.
ME/PE/Copy/Runs/... are just informations for BP's. These fields would be empty (in best case just existent with a few bytes, but as this depends on SQL EACH field would be as big as the field is, long int(16Bytes) for example), but still be loaded during query of each and every inventorylisting. Just for BP Issue there are 6 fields + on a that table which will most likely double the fields in that (and therefore double DB load).
If i understand the database correct from statement in this Topic there are 3 Tables:
Genereal Inventory-Table and spezific Iteminformation. Both are connected to a third table with general Iteminformations.
So you get in general-itemtable info about the item itself. What build-requirements and materiallist etc. NO me and NO pe OR run on those. Just info what that type of item do for ME0/PE0.
Now there is the 2nd Table of spezific item information. In that table are just the item-ID from the general-itemtable, ME, PE and RUN Information.
Now, if you list your inventory this polls your inventory-table and this give info what item it is from the general-table, as this has a fix amount of data (just as many as items are in game) and the related information where to fin details in the spezific table. The query on the spezific table is not done in this stage as this would mean a mass overload on information and just imagine how many items are there in game!
The best solution would be the idea with just use the field where the amount of an item ist stored to be used as informationfield if this is an bpo or not.
As items generaly have the ability to be repacked or not this field would be an boolean (1 bit). Just make this a 2 bit field an set states as follow:
0=Repacked
1=assembled (items like ships, modules etc)
2=BPO
3=BPC
now you could use the amount-field for whatever you want as long as you just parse this field by the client like: first 6 bit=runs, next 6=me, next6=pe.
I don't know how long this field is exactly but as you can have some billion Tritanium in one stack even a field length of 8 bit each would be possible.
As there are BP's with 1500 runs available the run-bit would have to be 9 bit at least. As ME/PE on smaller BP's is sometimes also >1000 3x 10bit would be fine for most cases.
This way you would even be able to display that information directly in the client with just one field an nearly no extraload on DB as the parsing of the amount-field could do the client (should be simple to implement to do such parsing depending on state of "package").
|